home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19971216-19980424 / 000140_news@newsmaster….columbia.edu _Sat Jan 31 00:53:25 1998.msg < prev    next >
Internet Message Format  |  2020-01-01  |  6KB

  1. Return-Path: <news@newsmaster.cc.columbia.edu>
  2. Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30])
  3.     by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id AAA24621
  4.     for <kermit.misc@watsun.cc.columbia.edu>; Sat, 31 Jan 1998 00:53:25 -0500 (EST)
  5. Received: (from news@localhost)
  6.     by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id AAA26439
  7.     for kermit.misc@watsun; Sat, 31 Jan 1998 00:53:24 -0500 (EST)
  8. Newsgroups: comp.protocols.kermit.misc
  9. Path: news.columbia.edu!sol.ctr.columbia.edu!gondor!newshub.sdsu.edu!news.sgi.com!nntprelay.mathworks.com!howland.erols.net!ix.netcom.com!gerlach
  10. From: gerlach@netcom.com (Matthew H. Gerlach)
  11. Subject: Re: Expect and Kermit (was: Re: frequent timeouts!)
  12. Message-ID: <gerlachEnK1G9.IBG@netcom.com>
  13. Organization: Netcom Online Communications Services (408-241-9760 login: guest)
  14. References: <6ao98e$p4h$1@apakabar.cc.columbia.edu> <gerlachEnIuIF.K4L@netcom.com> <6aonud$42r$1@apakabar.cc.columbia.edu>
  15. Date: Thu, 29 Jan 1998 16:50:33 GMT
  16. Lines: 84
  17. Sender: gerlach@netcom18.netcom.com
  18. Xref: news.columbia.edu comp.protocols.kermit.misc:8323
  19.  
  20. In article <6aonud$42r$1@apakabar.cc.columbia.edu> fdc@watsun.cc.columbia.edu (Frank da Cruz) writes:
  21. >In article <gerlachEnIuIF.K4L@netcom.com>,
  22. >Matthew H. Gerlach <gerlach@netcom.com> wrote:
  23. >: The kermit scripting language is a greate thing, most notably the fact
  24. >: that kermit scripts will run on many platforms.  That being said I find
  25. >: it very beneficial to control C-Kermit from Expect, and I work for a company
  26. >: that does a lot of it.  The main benefit is that one might need to write
  27. >: a script that controls many serial connections in conjuction with
  28. >: many connections to regular UNIX programs.  This appears to be easier with
  29. >: Expect.
  30. >:
  31. >Some concrete examples might be instructive.
  32.  
  33. Since I am a consultant for the company I mention above, I can't show code,
  34. but I will try to explain what they do.  In short they have a UNIX box
  35. that performs automated telephony testing.  This testing involves two 
  36. separate pieces.  One piece controls the end user's telephony equipment
  37. via a serial port.  The other piece is the actual voice frequency testing
  38. involved with DSP's.  The interface to voice frequency testing is an 
  39. interactive program.  So the scripts usualy send some commands to the
  40. telephone equipment, and once it is all set up, some commands get sent
  41. to the voice testing program.  So the Expect scripts coordinates the serial
  42. stuff with the DSP stuff.
  43.  
  44. At this point it is probably worth noting, that the company I mention was
  45. too cheap to pay for kermit to put on released product; so it "talks" to cu.  
  46. However, in house we tend to use kermit, because it's easier to use and has
  47. the wonderful "log session" feature.  I use kermit exclusively just because
  48. it is a great piece of software that is also well documented. I own copies
  49. of both revs of the book.
  50.  
  51. >: Furthermore, Tk/Expect allows one to easily put a "pretty face" 
  52. >: gui on said script.
  53. >: 
  54. >One ought to be able to do that anyway.  Code the user interface in Tk/Expect
  55. >or whatever, and the real stuff in the Kermit script.  Keeps the bosses happy
  56. >by looking pretty, and keeps the rest of us happy by working well :-)
  57. >
  58. >: In conclusion there are problems best solved by kermit scripts and problems
  59. >: best solved using Expect and there are even more problems best suited to 
  60. >: Perl, which I prefer.  Use the best tool to solve the problem.
  61. >: 
  62. >Agreed, provided it works.  If Kermit doesn't work with expect (I'm not
  63. >saying it doesn't), then the best tool is Kermit without expect.  Given the
  64. >amount of resources we have, there is a limit to the number of combinations
  65. >we can support.  But of course, that's where this newsgroup comes in handy.
  66. >
  67. >Meanwhile, I think this is a useful dialog.  If my understanding of the 
  68. >Expect approach is correct, it is basically a screen-scraper, looking for
  69. >the Kermit prompt, feeding commands to it, parsing the results, and so on
  70. >in a loop of some kind until the desired result is achieved.  But Kermit's
  71. >language includes a lot of features that don't fit this model, such as
  72. >FOR and WHILE loops, SWITCH statements, IF-ELSE constructions, even GOTOs.
  73. >I suppose these might be simulated at a "higher level", but isn't that
  74. >pushing the model a bit?  Also, note that every Kermit command returns a
  75. >status that can be tested by IF SUCCESS (or IF FAILURE); how do you do that
  76. >with Expect?
  77. >
  78.  
  79. Yes this is a very useful dialog, because we are discussing interesting
  80. ways to use kermit :)  As you say Expect is basically a screen-scaper.
  81. For those who are interested, Expect is an extension to the TCL scripting
  82. language.  The Expect extention simply spawns the desired program and
  83. opens a pseudo-tty to the STDIN/STDOUT of the child, in this case Kermit.
  84. The TCL scripting language does have the usual IF-ELSE, FOR and WHILE, 
  85. subroutines and stuff.  The expect command itself looks an awful lot like
  86. the use of minput followed by a switch.  As you point, however, 
  87. the kermit commands return a status that can be tested by 
  88. IF SUCCESS/FAILURE.  This information does not appear to be available to 
  89. Expect unless there is a kermit command like "print status of last command". 
  90. Is that a feature request?
  91.  
  92. As you point out above, there are cases when one should program the "real"
  93. stuff in kermit and glue it to a user interface or whatever else needs gluing.
  94.  
  95. At this point I would like by throwing out yet another scripting
  96. language, Perl.  One can do the same thing in Perl as one does with
  97. Expect, and that is what I personally do because I find Perl to be
  98. a much more powerful programming language.  Another interesting point
  99. is that a common question to the perl news group is "how do I control
  100. a serial port from perl"?  Well, I always tell them, have Perl "talk"
  101. to kermit!  I think now I will tell them, have perl talk to kermit scripts.
  102.  
  103. Matthew H. Gerlach